Do we want to avoid locking when running under mutmut?

yes, but only when fixtures already exist downloaded - we could skip locking then.

Since mutmut has multiple phases, the fixtures exist after the first stat collection run (this phase happens before the mutation tests start parallely)

Couldn't another test run delete the fixtures folder while it's running if we don't lock?

yeah makes sense - is there a concern given usually the fixtures persist?
I was thinking since mutmut runs parallely - acquiring the lock for each of these process might lead to sequential startup for each of the mutation run? (which should cost some time)
But its true that if somehow fixtures are deleted, then the current workers at that time would fail

I suppose it depends how mutmut runs in parallel. If it's entirely separate processes, without this lock, each one would blow away the fixtures directory when it starts; but with the lock it'll be serialized.

If mutmut works like xdist, then it'll still run in parallel.

In mutmut a separate pytest process is launched for each mutation, so these run independently in parallel (i think unlike xdist?) Also, from all my runs i see the fixtures persist, should we take a tradeoff then over a rare chance of deletion? Here's a CI test run - https://github.com/souradeep-das/execution-specs/actions/runs/17051785519

See here. While the tarball is being extracted, the state on disk is uncertain.

I think we have three options: (1) have each process use its own fixtures directory; (2) use an exclusive lock during extraction, a shared lock during test runs, and write the currently extracted tests to disk somewhere; or (3) live with serialized tests.

I'd pretty strongly prefer not ignoring this issue, because (unless I'm misunderstanding) we might end up in the situation where a mutmut process only sees 10% of the tests and then reports a false positive.

This exits the context manager and, as I far understand portalocker, releases the lock. We need to hold the shared lock for the duration of the test run to prevent another process coming in and taking the exclusive lock.

oh yess, updated to hold the shared lock entirely now. used a while true loop before, that was confusing so removed it!
also tested with deleting fixtures when running mutmut